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REPLY BRIEF 



Mail Stop Appeal Brief - Patents 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



Dear Sir: 

In response to the Examiner's Answer mailed March 30, 2005, Appellants present 
this Reply Brief. Appellants respectfully request that this Reply Brief be entered 
pursuant to 37 C.F.R. § 41.41 and considered by the Board of Patent Appeals and 
Interferences. 
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REPLY TO EXAMINER'S ANSWER 

First Ground of Rejection ; 
Claim 1 : 

In the Appeal Brief, Appellants argue that He fails to anticipate a client using a 
capability credential to request an access interface document to access a service, the 
client receiving the access interface document , wherein the access interface document 
comprises an interface for accessing only a portion of the service's capabilities , and the 
client using the interface from the access interface document to access a capability from 
the portion of the service's capabilities. Instead, He presents a hierarchy of tickets used 
for access control. He also teaches controlling access to network elements through the 
use of an authentication server, a credential server and a network element access server 
(He, column 2, lines 12-16). However, as argued in the Appeal Brief, He does not 
disclose anything regarding an access interface document comprising an interface for 
accessing only a portion of a service's capabilities, as the Examiner contends. He is not 
concerned with access interface documents by which a client accesses a service. The 
access control credentials and tickets, such as He's general and session tickets, are used 
only for access control, not as interface documents. 

In the Examiner's Answer, the Examiner repeats his assertion that He's pull-down 
menus "listing available services" are access interface documents. Specifically, the 
Examiner argues that "a document or web page with a graphical user interface (GUI) 
such as pull-down menus listing available services to which the client is 
allowed/authorized to access" is an access interface document to access a service. 

However, nowhere does He describe that a web page including pull-down menus 
listing network elements in an access interface documents that includes an interface for 
accessing those network elements or any other portion of a service's capabilities. 
Instead, He's pull-down menus only allow a user to select a network element to access - 
without providing any interface for accessing that network element. He teaches that "the 
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user is permitted to access pull down menus to identify those network elements" to access 
(emphasis added, He, column 26, lines 58-60). Thus, He teaches the traditional use of 
pull down menus in their conventional manner to select from among multiple choices. 
He also teaches that a user "clicks on a desired network element to select it, or otherwise 
specifies a preference for connectivity with a selected network element" (emphasis added, 
He, column 26, lines 62-64). Thus, He describes mechanisms other than the pull-down 
menus for a user to select a network element - supporting Appellants 5 argument that He 
is using pull-down menus in a purely traditional use as selection mechanisms - not as 
interface documents. 

Additionally, after He's user selects a network elements, whether or not via pull- 
down menus, He's user element local access control system sends an access request 
including a general ticket to the network security server, which verifies the general ticket 
and returns a session ticket for communicating with the selected network element (He, 
column 27, lines 40-55). He goes on to describe how the user element communicates 
with the network element using the session encryption key from the session ticket (He, 
column 28, lines 9-33). However, He does not teach that the user element uses an 
interface from the web page including the pull down menus to access either the network 
security server or the network element. Instead, as noted previously, He is merely using 
pull-down menus, as well as other mechanisms, to allow a user to select a particular 
network element to access. After the user has made such a selection, He does not refer to 
using any interface from the web page including the pull-down menus (which the 
Examiner's equates to an access interface document) to access the selected network 
element, or any other capability of a service. 

The Examiner, in the Examiner's Answer, also equates one of He's clients "using 
the received credential ticket containing a list of user credentials issued by the credential 
server 204 to request a document or a GUI (or a web page) with the pull-down menus, via 
the access server 206 and the security server 208, in order to access the available 
services/network elements according to his capability credential" (parenthesis in original) 
as using a capability credential to request an access interface document to access a 
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service. However, He clearly teaches that the general ticket, which the Examiner equates 
to a capability credential, is used to request access to a network element only after the 
user has selected the network element via He's pull down menus (He, column 27, lines 
40-56). Thus, a client in He's system does not use the general ticket to request a 
document, GUI, or web page, as suggested by the Examiner. He fails to mention a client 
requesting such a document, GUI, or web page using the general ticket. Instead, He 
teaches that the general ticket is "presented to the network security server each time the 
user element initiates a communication session" and that if the general ticket is 
authenticated the network security server provides a session ticket "used by the user 
element to communicate with the elected network element" (He, column 2, lines 36-47). 
Thus, when one of He's clients uses a general ticket (which the Examiner argues is a 
capability credential) the user has already selected a network element and thus the client 
cannot be requesting a document, GUI, or web page including the pull down menus 
(which the Examiner equates to an access interface document) as the Examiner contends. 

Furthermore, the Examiner also argues (in the Examiner's Answer) that when a 
user in He's system makes an access request by selecting/clicking on one of the available 
network elements listed by the pull-down menus, the client is using the interface from an 
access interface document to access a capability from said portion of the service's 
capabilities. However, He describes how when the user selects a network element, the 
user is performing an authentication function by presenting a general ticket in order to 
obtain a session encryption key with the session ticket (He, column 2, lines 36-47). He 
states only that the "user sends a message to the network element access server" to 
request "a ticket to access a specified network element" (He, column 20, lines 27-30). He 
does not describe sending a message to the network element access server as using an 
interface from the pull-down menus used to select the desired network element. He 
simply does not describe requesting a ticket as using an interface from an access 
interface document to access a capability from a portion of a service's capabilities. 

The Examiner also contends that He's use of a general ticket to receive a session 
ticket corresponds to the client using a capability credential to request an access interface 
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document to access the first service, and further argues that He's use of a pull down menu 
corresponds to a client receiving an access interface document and using the interface 
from the access interface document to access a capability from said portion of the first 
service's capabilities. However, as discussed previously, He clearly teaches that a user 
uses the pull down menu (which the Examiner equates to using an interface from an 
access interface document to access a capability from a portion of a service's capabilities) 
to first select a network element for which a user then obtains a session ticket (which the 
Examiner equates to requesting an access interface document). Thus, a client using He's 
general ticket to receive a session ticket cannot correspond to a client using a capability 
credential to request an access interface document, as the Examiner contends. 

Claim 18 : 

For a rebuttal of the Examiner's arguments in the Examiner's Answer regarding 
claim 18, please see the above discussion regarding claim 1. 

Claim 35 : 

For a rebuttal of the Examiner's arguments in the Examiner's Answer regarding 
claim 35, please see the above discussion regarding claim 1. 

Second Ground of Rejection : 

Claims 2, 3, 19, 20. 36 and 37 : 

Appellants argue that He in view of Pulliam fails to teach wherein using a 
capability credential to request an access interface document comprises sending an 
advertisement request message in a data representation language , wherein the 
advertisement request message includes the capability credential. The Examiner 
recognizes that He fails to teach sending an advertisement request message in a data 
representation language, and relies upon Pulliam to disclose this functionality. Pulliam 
teaches an online shopping communication schema for communicating online shopping 
orders such as vehicle orders (Pulliam, Abstract) and has nothing to do with a client 
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requesting an interface document comprising an interface usable by the client to access 
only a portion of a service's capabilities. 

The Examiner holds that the pull-down lists in Pulliam that include available 
automobile makes and models (Pulliam, column 13, lines 31-37) are an access interface 
document to access the available makes and models. Appellants disagree. Pulliam never 
mentions anything regarding an access interface document, nor about using such pull- 
down lists as an access interface document that comprises an interface for accessing a 
portion of a service's capabilities . Instead, Pulliam teaches that the client uses a user's 
selections among the pull-down lists to compile an XML message "that requests a list of 
matching vehicles in inventory database 612" (Pulliam, column 13, lines 37-49). Thus, 
rather than being an access interface document as the Examiner contends, the pull-down 
lists, and the data that make up such lists, are clearly search criteria, and therefore just 
data, to be sent as part of a database search request. Appellants note that the Examiner 
has never provided any rebuttal to Appellants' argument that Pulliam' s pull-down lists 
are used to specify search criteria rather than as access interface documents. 

The Examiner's Answer repeats the Examiner's statement asserting that 
Appellants are attempting to attack the cited references individually. However, the 
Examiner is ignoring Appellants' arguments in previous responses stating that even if 
He's system were modified so that a user requested a ticket by sending a request message 
in a data representation language, the request would still be for just a ticket, not an 
interface document comprising an interface usable by the client to access only a portion 
of a service's capabilities (Response dated June 28, 2004, page 14, lines 10-13, Appeal 
Brief dated January 11, 2005, page 14, lines 7-16). Furthermore, the Examiner has also 
ignored Appellants' previous rebuttal to the Examiner's statement regarding attacking the 
cited references individually (Appeal Brief dated January 1 1, 2005, page 14, lines 18-25). 

Furthermore, the Examiner has failed to provide any rebuttal to Appellants' 
argument that Pulliam fails to disclose anything regarding sending an advertisement 
request message. As stated in the Appeal Brief, the searching of an online automobile 
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database according to user specified search criteria in Pulliam has nothing to do with an 
advertisement request message. The Examiner's cited passages (Pulliam, column 14 5 
lines 34-45, and column 15, lines 38-42) refer only to a locate server that uses PKI 
encrypted user credentials to provide access control. Neither of these passage teaches 
anything regarding sending an advertisement request message. Pulliam only teaches the 
use of XML to describe the search criteria and the corresponding search results (Pulliam, 
column 13, lines 25-29). Pulliam fails to teach sending an advertisement request 
message in a data representation language. Appellants submit that sending an 
advertisement request message is very different than sending search criteria and search 
result messages in XML. Just because XML is a data representation language, does not 
mean that using XML for search criteria or search result messages corresponds to or 
suggests sending an advertisement request message in a data representation language. 

Claim 4 : 

Appellants' argue, regarding claim 4, that He in view of Pulliam does not teach 
generating a custom advertisement in response to receiving the advertisement request 
message. 

The Examiner contends, in the Examiner's Answer, that "the server [in He] 
generates pull-down menus to identify those capabilities to which the client is 
allowed/authorized to access" (emphasis added) citing He, column 26, lines 58-65 and 
Pulliam, column 13, lines 34-40). However, as argued in Appellants' Appeal Brief, the 
pull-down menus in He and Pulliam referred to by the Examiner have nothing to do with 
generating a custom advertisement as an access interface document according to the 
portion of the service's capabilities that the capability credential indicates the client is 
allowed to access. He's pull-down menus "identify those network elements" to which the 
user is allowed access. The cited passage of Pulliam pertains to "pull-down lists of 
available makes and models" which may be used to select "preferences" for "matching 
vehicles" as described above regarding claim 2. Pulliam' s teachings have nothing to do 
with generating a custom advertisement according to a portion of a service's capabilities. 
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The Examiner also refers to He's and Pulliam' s pull-down menus as identifying 
capabilities. He, however, does not teach using pull-down menus to identify capabilities, 
but instead uses pull-down menus to identify those specific network elements with which 
a user may communicate (He, column 26, lines 58-65), not any particular capabilities or 
portions of the capabilities of a service that a user may access. Similarly, Pulliam never 
describes pull-down menus as identifying service capabilities. Instead, Pulliam uses pull- 
down lists as one example of collecting search criteria from a user (Pulliam, column 13, 
lines 34-37). 

As argued in Appellants' Appeal Brief, He and Pulliam, both singly and in 
combination, fail to teach generating and sending, in response to receiving the 
advertisement request message, an advertisement request response message which 
includes a custom advertisement generated according to a portion of a service's 
capabilities that a client is allowed to access as indicated by a capability credential. 

Claims 5. 22. and 39 : 

Appellants argue in the Appeal Brief that He in view of Pulliam does not teach or 
suggest a custom advertisement that specifies an XML schema defining messages to be 
sent by the client to the service and messages to be sent from the service to the client to 
use the portion of the service's capabilities. The portions cited by the Examiner (Pulliam, 
column 13, lines 22-42, column 15, lines 39-43 and column 16, lines 40-50) refer to the 
use of XML "to support application-to-application data exchange formats." In Pulliam, 
XML is used to describe the data content of messages, not to define the messages 
themselves. XML, as used by Pulliam, does not define messages to be sent by the client 
to the service nor messages to be sent from the service to the client to use the portion of 
the service's capabilities. 

In response to the above argument, the Examiner again cites portions of Pulliam 
(column 13, lines 22-42; column 15, lines 39-43; and column 16, lines 40-50) that refer to 
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Pulliam's use of XML to send various messages. However, as stated previously, Pulliam 
does not mention an XML schema defining messages to be sent by the client to the 
service, nor does he describe messages to be sent from the service to the client. The 
Examiner's total argument is that Pulliam uses XML to exchange messages. However, 
just sending and receiving messages in XML does not teach, suggest, or inherently 
include the use of an XML schema defining the messages. The Examiner has not cited 
any portion of either He or Pulliam that describes, or even mentions, such a schema. Nor 
has the Examiner demonstrated that such a schema is inherent in Pulliam' s use of XML 
messages. Thus, the Examiner has completely and repeatedly failed to rebut Appellants' 
arguments regarding claim 5. 

Appellants also argue in the Appeal Brief that the rejection of claim 5 is further 
improper because the Examiner has not explained how the cited teachings of Pulliam (the 
use of XML messages to submit search requests) applies to He's system. As stated 
above, He fails to mention anything regarding XML messages, or search messages. 
Furthermore, the Examiner fails to explain how Pulliam suggests modifying He's system. 
Nor does the Examiner provide any motivation for combining the online ordering system 
of Pulliam with the secure access method of He. The use of an XML schema in Pulliam 
to describe data to be exchanged in online shopping does not have any relevance to the 
access control ticket requests in He. Therefore, the combination of references is 
improper. Appellants note that the Examiner has failed to provide any rebuttal to this 
argument. 

Claims 13, 14, 30, 31 47 and 48 ; 

Appellants argue that He in view of Pulliam fails to teach wherein said access 
interface document comprises a schema defining messages for accessing said portion of 
the first service's capabilities, wherein said using the interface from said access interface 
document to access a capability comprises sending a message according to said schema 
to the first service. 
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In the Examiner's Answer, the Examiner refers to the Examiner's arguments 
regarding claims 5, 22, and 39. As such, the arguments presented above regarding claims 
5, 22, and 39 also apply here. 

Furthermore, the Examiner has failed to provide any rebuttal to Appellants 
argument regarding how the pull-down menus of He do not use or comprise a schema 
defining messages for accessing a portion of a service's capabilities. Instead, using a 
pull-down menu only involves user selection. Also, Pulliam teaches that his pull-down 
menus are used to specify search criteria. Pulliam does not teach that using his pull-down 
menus includes sending messages specified in a schema, as the Examiner suggests. 

As with the Examiner's rejection of claims 5, 22, and 39, discussed above, the 
Examiner fails to explain how the cited teachings of Pulliam are combined with He's 
system. The Examiner also fails to provide any motivation for combining the online 
ordering system of Pulliam with the secure access method of He. As argued in the 
Appeal Brief, no combination of He and Pulliam results in a method wherein the access 
interface document comprises a schema defining messages for accessing a portion of the 
first service's capabilities, wherein the using the interface from the access interface 
document to access a capability comprises sending a message according to the schema to 
the first service, as asserted by the Examiner. 

Claims 15, 32 and 49 : 

Appellants argue in the Appeal Brief that He in view of Pulliam fails to teach 
wherein said access interface document comprises a message schema defining messages 
for accessing the portion of the first service's capabilities, wherein said using the 
interface from the access interface document to access a capability comprises the client 
using the access interface document to construct a message gate for sending messages to 
the first service, wherein the message gate embeds the capability credential in each 
message . 
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The Examiner's Answer states, "Pulliam teaches a message client 924 provides 
the required functions to receive the XML formatted document, then generates and sends 
the XML messages and application credentials to and from the server" and cites column 
15, lines 38-43 of Pulliam. However, as argued in the Appeal Brief, Pulliam's teachings 
do not disclose an access interface document comprising a message schema defining 
messages for accessing a portion of a service's capabilities. The Examiner has also 
argued (such as regarding claim 1) that He's pull-down menus (of network elements) are 
access interface documents. However, the Examiner has failed to point out any passage 
of He or Pulliam that discloses wherein the pull-down menus comprise a message schema 
defining messages, as recited in claim 15. In fact, neither He nor Pulliam ever mention 
any sort of access interface document comprising a message schema defining messages 
for accessing a portion of a service's capabilities. 

Furthermore, the cited passage of Pulliam does not teach a message client that 
embeds the capability credential in each message. Instead, the cited passage only 
describes how Pulliam' s message client 924 sends and receives XML messages. 
Nowhere does Pulliam mention a message gate embedding a capability credential in each 
message. The Examiner is merely speculating in hindsight regarding the embedding of a 
capability credential with every message. 

Appellants note that the Examiner's Answer merely repeats the Examiner's 
previous arguments without providing any rebuttal of Appellants' arguments as presented 
in the Appeal Brief 

Claims 16, 33 and 50 ; 

Appellants argue, regarding claim 16, that He in view of Pulliam fails to teach 
wherein the message gate checks each message for compliance with the message schema . 
The Examiner, in the Final Office Action and the Advisory Action, cites column 16, lines 
40 - 50 of He. However, the cited portion of He, only describes He's use of a 
registration database and how He's authentication server 202 maintains a database of user 
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account records. The cited passage has no relevance on a message gate that checks each 
message for compliance with a message schema. He does not teach anything regarding a 
message gate that checks each message for compliance with a message schema, as recited 
in claim 16. 

The Examiner's Answer cites column 15, lines 26-43 and column 16, lines 40-50 
of Pulliam and argues that Pulliam's statement regarding how message client 924 
provides the required functions to generate, send and receive XML messages teaches a 
message gate that checks each message for compliance with a XML message schema. 
However, the cites passages of Pulliam fail to mention anything regarding an XML 
schema or about message client 924 checking messages for compliance with such a 
schema. As argued above and in the Appeal Brief, He in view of Pulliam fails to disclose 
a message schema defining messages to access a portion of a service's capabilities 
(please refer to the arguments presented above regarding claims 5, 22, and 39). 

The Examiner appears to be arguing that providing functions to generate, send, 
and receive XML messages, as mentioned by Pulliam inherently includes a message gate 
that checks each message for compliance with a message schema. However, XML 
messages can easily be generated, sent, and received without any such message gate 
checking each message for compliance with a message schema as in well-known in the 
art of network communication. Without some specific teaching or suggestion in either 
He or Pulliam regarding such a message gate, the Examiner's argument amounts to 
nothing more than hindsight speculation. 

Claim 21 : 

For a rebuttal of the Examiner's arguments in the Examiner's Answer regarding 
claim 21, please see the above discussion regarding claim 4. 

Claim 38: 
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For a rebuttal of the Examiner's arguments in the Examiner's Answer regarding 
claim 38, please see the above discussion regarding claim 4. 
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CONCLUSION 



For the foregoing reasons submitted in the Appeal Brief and this Reply Brief, it is 
submitted that the Examiner's rejections of claims 1-5, 13-22, 30-39 and 47-51 was 
erroneous. Reversal of the Examiner's decision is respectfully requested. 

The Commissioner is authorized to charge any fees that may be due to Meyertons, 
Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5181-70500/RCK. 
This Reply Brief is submitted with a return receipt postcard. 



Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: May 3 1,2005 
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